Product Requirements Document (PRD)

Shrimp Farming Management Platform

Roadmap note: Source roadmap does not contain an explicit Sprint 6 entry. This PRD does not invent Sprint 6 scope.

Implementation note: Requirement wording uses status labels to distinguish current code behavior from planned roadmap scope. Items marked Planned or Partial remain in the PRD but must not be treated as already delivered.

Table of Contents

1. Executive Summary
2. Product Overview
3. User Personas
4. Product Functions
5. Functional Requirements
6. Non-Functional Requirements
7. Success Metrics
8. Yêu cầu AI riêng / AI-Specific Requirements
9. Risks and Dependencies
10. Appendix A — Product Roadmap
11. Appendix B — Open Questions
12. Appendix C — Glossary
13. Appendix D — Requirement Traceability
14. Appendix E — Document History

1. Executive Summary

1.1 Product Vision

The Shrimp Farming Management Platform is designed to provide a centralized platform for managing shrimp farming operations across farms, ponds, crops, environmental monitoring, feeding, incidents, IoT devices, reporting, operational knowledge, and AI-assisted decision support.

The platform evolves through three major product stages:

Release 1 — Core Platform

Establish the operational foundation for:

• authentication and user management;
• farm, pond and crop management;
• water monitoring;
• alert management;
• feeding records;
• farming logs;
• reports;
• incident/ticket management.

Release 2 — IoT Integrated Platform

Extend the Core Platform with:

• IoT device management;
• sensor/device assignment;
• device monitoring;
• manual and automatic device control;
• device control history;
• sensor status and sensor history.

Release 3 — AI Enabled Platform

Extend operational data and IoT capabilities with:

• AI feeding suggestions;
• Farming Handbook;
• contextual AI Chatbot;
• preliminary image analysis;
• alerts/recommendations;
• growth assessment;
• phased energy optimization;
• configurable operational rules;
• configurable AI knowledge/data sources/safety policies;
• scheduled reporting.

The product direction can therefore be summarized as:

Manage
  ↓
Monitor
  ↓
Alert
  ↓
Operate
  ↓
Automate
  ↓
Recommend
  ↓
Assist

1.2 Problem Statement

Shrimp farming operations involve multiple types of information that must be managed together:

• users and operational responsibilities;
• farms, ponds and crops;
• water-quality measurements;
• feeding records;
• farming logs;
• minerals and siphon records;
• sensor and equipment status;
• device operation;
• alerts and incidents;
• technical-support tickets;
• historical reports;
• farming knowledge.

Without a centralized system, these activities can become fragmented and difficult to trace.

The platform addresses this by providing a common operational data model and workflow, then progressively adding IoT integration and AI capabilities on top of that operational foundation.

1.3 Product Goals

2. Product Overview

2.1 Product Scope

The product scope includes the following major capability groups:

2.2 Product Delivery Stages

Release 1 — Core Platform

Release 1 establishes the fundamental operational workflows:

Users
  │
Farm / Pond / Crop
  │
  ├── Water Monitoring
  ├── Alerts
  ├── Feeding
  ├── Farming Logs
  ├── Reports
  └── Tickets

Release 2 — IoT Integrated Platform

Release 2 adds physical device and sensor integration:

Core Platform
      │
      ├── Sensors
      ├── IoT Devices
      ├── Device State
      ├── Manual Control
      ├── Automatic Rules
      └── Device History

Release 3 — AI Enabled Platform

Release 3 adds intelligent assistance:

Farm + Pond + Crop
        │
Environmental Data
        │
Feeding Data
        │
Alerts + Handbook
        │
        ├───────────────┐
        ▼               ▼
AI Feeding         AI Chatbot
Suggestion              │
                        ├── Confidence
                        ├── References
                        └── Ticket / KTV Escalation

2.3 Target Users

Admin

Primary responsibilities

• Manage user accounts and roles.
• Assign operational access scope.
• Manage farms/ponds where permitted.
• Manage configuration.
• Manage Farming Handbook.
• Assign/reassign Technical Staff.
• Manage reporting.
• Calib/monitor devices.
• Configure chatbot knowledge and policies.

Primary modules

Authentication & User Management, Farm Management, Tickets, Logs, Reports, System Configuration.

Farm Owner / Chủ hộ

Primary responsibilities

• Monitor farm and pond operations.
• Review environmental status.
• Review feeding information.
• View alerts and reports.
• Use AI features where authorized.
• Schedule weekly reports.

Primary modules

Dashboard, Feeding, Alerts, Reports, Logs, AI Suggestion, AI Chatbot, AI assesses productivity, AI recommends action, AI optimizes energy.

Technical Staff

Primary responsibilities

• Be assigned to ponds where applicable.
• Receive technical tickets.
• Accept and process incidents.
• Update ticket progress.
• Close resolved tickets.
• Calib/monitor devices.
• Receive escalation/email notifications.

Primary modules

Farm/Pond assignment, Incident/Ticket Management, Alerts.

Authorized Farm Operator / Support Staff

Primary responsibilities

• Access assigned farm/pond scope.
• Enter operational data.
• Record feeding.
• View dashboards and alerts.
• Control permitted devices.
• Create technical tickets.
• Use AI Chatbot within authorization scope.

3. User Personas

3.1 System Administrator (Admin)

Profile

User responsible for managing the overall platform configuration and user access.

Goals

• Maintain account and role information.
• Control access to farms, ponds and tickets.
• Maintain system configuration.
• Ensure operational master data remains usable.
• Configure ticket/alert SLA and notification behavior.
• Maintain chatbot knowledge and data-source configuration.

Pain Points Addressed

• Uncontrolled access to operational information.
• Manual configuration changes.
• Difficulty tracing role/permission changes.
• Fragmented business configuration.

3.2 Farm Owner

Profile

User responsible for one or more farms and their operational performance.

Goals

• Understand pond status quickly.
• Identify environmental abnormalities.
• Track feed usage and farming productivity.
• Monitor alerts and incidents.
• Receive regular reports.
• Use AI assistance for farming decisions.

Pain Points Addressed

• Fragmented farm information.
• Lack of consolidated historical data.
• Difficulty comparing environmental data and farming activities.
• Slow access to relevant operational knowledge.

3.3 Support Staff

Profile

User performing day-to-day pond operations.

Goals

• Enter accurate operational records.
• Record feeding activities.
• Review pond conditions.
• Respond to alerts.
• Control permitted equipment.
• Report technical problems.

3.4 Technical Staff

Profile

Technical staff responsible for pond or equipment support.

Goals

• Know which ponds are assigned.
• Receive technical incidents.
• Understand the problem context.
• Track response and processing times.
• Update resolution progress.

4. Product Functions

4.1 Authentication & User Management

4.2 Farm / Pond / Crop Management

4.3 Water Monitoring Dashboard

4.4 Alert Management

4.5 Feeding Management

4.6 Productivity & Farming Logs

4.7 Reports & Excel Export

4.8 Incident / Ticket Management

4.9 IoT Device Control

4.10 AI Chatbot

4.11 AI Image Analysis

4.12 AI Growth & Productivity Assessment

4.13 AI Energy Optimization

4.14 System Configuration

4.14 Current Implementation Status Summary

Status legend:

• Implemented: backend and/or product surface exists in the current codebase.
• Partial: core code exists, but coverage, UI, authorization or automation is incomplete.
• Planned: requirement remains in product scope but is not implemented in the current codebase.

5. Functional Requirements

5.1 Authentication & User Management

FR-AU-001 — Login

The system shall allow a valid user to authenticate and access the platform according to the user's assigned role and scope.

FR-AU-002 — Logout

The system shall allow authenticated users to terminate their active session.

FR-AU-003 — Forgot / Reset Password

The system shall provide a password recovery and reset process.

Detailed token lifetime and password policy are currently TBD.

FR-AU-004 — User Administration

Authorized administrators shall be able to:

• create user accounts;
• edit user accounts;
• disable user accounts;
• assign roles.

FR-AU-005 — Operational Scope

The system shall support assignment of user access by role to applicable:

• farms;
• ponds;
• tickets.

A user shall not implicitly gain access outside assigned scope.

Current implementation status: Partial. Scope data is present in authentication/session context and applied in several dashboard, pond and ticket queries. Some domain/admin authorization checks are temporarily bypassed in code and must be hardened before this requirement can be considered fully implemented.

FR-AU-006 — KTV Administration

The system shall support creation and/or assignment of KTV users according to administrative permissions.

FR-AU-007 — Session Timeout

The system shall automatically expire inactive sessions according to configured session timeout behavior.

Exact timeout duration is TBD.

FR-AU-008 — User Management Audit

The system shall record audit logs for:

• user-management actions;
• permission/role changes.

Minimum audit fields and retention duration are TBD.

5.2 Farm / Pond / Crop Management

FR-FP-001 — Farm Management

Authorized users shall be able to:

• create a farm;
• view a farm;
• edit a farm;
• close a farm.

Current implementation status: Partial. Farm create/view/edit, status update and delete/soft-delete flows exist. The product term “close farm” maps to farm status closure where supported; final UX wording and authorization rules should be aligned with the implemented status/delete behavior.

FR-FP-002 — Pond Management

Authorized users shall be able to create, view and edit ponds belonging to a farm.

FR-FP-003 — Crop Management

The system shall allow authorized users to create, view and edit farming crops/cycles for individual ponds.

FR-FP-004 — Closed Crop Protection

Once a crop is closed, operational crop data shall not be editable except by users with explicitly authorized special permission.

Current implementation status: Partial. Crop close and override APIs exist, but several crop permission checks are temporarily bypassed in code. This requirement remains open until closed-crop edit restrictions are enforced end-to-end.

FR-FP-005 — Pond KTV Assignment

Authorized users shall be able to assign a KTV to one or multiple ponds.

FR-FP-006 — Pond Overview

The system shall provide a pond list showing overall operational context including:

• farming day;
• alerts;
• sensor status;
• device status.

5.3 Water Monitoring Dashboard

FR-WM-001 — Farm Overview

The system shall display farm overview information containing the farm's ponds and their alert status.

Current implementation status: Partial. Backend farm/owner dashboard data and owner web dashboard exist. The dedicated web Water Monitoring route is still a placeholder.

FR-WM-002 — Pond Environmental Dashboard

The pond dashboard shall display six monitored indicators:

• pH;
• DO;
• salinity;
• algae/ORP;
• alkalinity;
• temperature.

The source groups “tảo/ORP” as one dashboard item; final domain definition is TBD if these represent separate measurement types.

FR-WM-003 — Historical Chart

The system shall provide time-series visualization for monitored indicators.

Users shall be able to filter by:

• 24 hours;
• 7 days;
• 30 days;
• custom period.

FR-WM-004 — Safe Threshold Visualization

The system shall display configured safe thresholds and visually identify times when measurements exceed allowed thresholds.

FR-WM-005 — Farming Context

The pond dashboard shall display:

• farming day;
• pond area;
• density;
• shrimp size.

FR-WM-006 — Sensor Status

The system shall display sensor status as:

• online;
• offline;
• error.

FR-WM-007 — Sensor History

Authorized users shall be able to view historical sensor readings.

5.4 Alert Management

FR-AL-001 — Environmental Alert

The system shall create an alert when a water-quality indicator exceeds its configured threshold.

FR-AL-002 — Sensor / Device Alert

The system shall create an alert when a sensor or device:

• loses connection; or
• reports an error.

FR-AL-003 — Alert Filters

The system shall provide alert filtering by:

• type;
• severity;
• pond;
• farm;
• status;
• time.

Current implementation status: Partial. Backend alert filters exist and pond warning tabs consume alert data. The standalone web Alerts page is not implemented yet.

FR-AL-004 — Alert Lifecycle

The alert workflow shall support:

New
 ↓
Acknowledged
 ↓
In Progress
 ↓
Closed

Exact transition permission rules are TBD.

5.5 Feeding Management

FR-FD-001 — Feeding Entry

The system shall allow feeding data to be entered for each feeding session, including:

• feed type;
• amount;
• time;
• person entering the record;
• notes.

FR-FD-002 — Feeding Response

The system shall allow feeding response to be recorded, including:

• strong feeding;
• weak feeding;
• feed remaining.

FR-FD-003 — Feeding History

The system shall provide feeding history by:

• day;
• week;
• farming crop/cycle.

FR-FD-004 — Actual Feed Override

Where a suggested amount exists, users shall be able to record an actual feeding amount different from the suggestion.

The system shall support storing the reason when required.

The rule defining when a reason is mandatory is TBD.

FR-FD-005 — Daily AI Feeding Suggestion

The system shall provide a suggested total daily feeding amount using:

• farming day;
• shrimp size;
• shrimp quantity;
• density;
• pond area;
• environmental data.

Current implementation status: Planned. The current backend suggestion endpoint exists as a contract stub and returns unavailable because AI feeding is scheduled for a later MVP/release step.

FR-FD-006 — Feed by Session

The system shall suggest:

• feeding amount by session;
• suitable feeding time/time window.

Detailed recommendation algorithm is TBD / Pending Domain Confirmation.

Current implementation status: Planned. No implemented per-session recommendation algorithm is present in the current codebase.

FR-FD-007 — Environmental Feeding Warning

At feeding time, the system shall warn users when:

• DO is low; or
• pH is abnormal.

DO and pH threshold values are TBD.

FR-FD-008 — PCR/FCR

The system shall calculate PCR/FCR according to an approved formula.

Until the formula is approved, this requirement remains:

Pending Business Formula Confirmation

Current implementation status: Planned. The current API returns unavailable until the approved PCR/FCR formula is supplied.

5.6 Productivity & Farming Logs

FR-LOG-001 — Manual Environmental Data

The system shall allow users to manually record environmental values by pond/date, including:

• morning pH;
• afternoon pH;
• alkalinity;
• other supported environmental indicators.

FR-LOG-002 — Mineral Records

The system shall support mineral records including:

• Bicar;
• Super M;
• K;
• CaCO3;
• CaO;
• Zeo;
• extensible mineral categories.

FR-LOG-003 — Siphon Records

The system shall support:

• morning siphon;
• afternoon siphon;
• total siphon;
• pond-bottom condition notes.

FR-LOG-004 — Farming Log

The system shall provide operational logs by:

• day;
• week;
• farming crop/cycle.

FR-LOG-005 — Same-Day Editing

The system shall allow records to be edited during the current day before end-of-day data is finalized.

End-of-day finalization behavior is TBD.

Current implementation status: Partial. Create/update/delete APIs exist for farming-log records. Explicit end-of-day locking/finalization is not implemented.

FR-LOG-006 — Productivity Summary

The system shall display:

• daily productivity summary per pond;
• total productivity for the farming crop/cycle.

The precise productivity formula is TBD.

5.7 Reports & Excel Export

FR-RP-001 — Water Monitoring Report

The system shall provide a report of the six monitored water indicators by:

• pond;
• selected time period.

FR-RP-002 — Device Report

The system shall report device activity including:

• ON/OFF history;
• running time;
• number of errors.

FR-RP-003 — Feeding Report

The system shall provide feeding reports by:

• feeding session;
• day;
• week;
• farming crop/cycle.

PCR/FCR shall be included when the required approved formula is available.

FR-RP-004 — Farming Operation Report

The system shall report:

• manually entered environmental data;
• minerals;
• siphon data.

FR-RP-005 — Incident / Ticket Report

The system shall provide ticket reports including:

• response time;
• processing/resolution time;
• assigned processor.

FR-RP-006 — Excel Export

The system shall support exporting applicable reports to Excel.

Detailed workbook layout, columns and maximum export size are TBD.

FR-RP-007 — Scheduled Weekly Reports

Admin and Farm Owner shall be able to schedule weekly reports to be sent by email.

Detailed report content, recipient rules, delivery schedule and timezone behavior are TBD.

Current implementation status: Planned. Current code supports manual/on-demand Excel export jobs and report history, but not scheduled weekly email reports.

5.8 Incident / Ticket Management

FR-TK-001 — Ticket Creation

Users shall be able to create equipment/failure tickets from:

• Website;
• Mobile App.

FR-TK-002 — Ticket Attachments

The system shall allow images and/or videos to be attached when creating a ticket.

Supported file types, size limits and retention are TBD.

FR-TK-003 — Ticket List

The system shall provide ticket filtering by:

• status;
• type;
• assignee;
• pond;
• time.

FR-TK-004 — KTV Assignment

Authorized administrative users shall be able to:

• assign KTV;
• reassign KTV;

to handle a ticket.

FR-TK-005 — Ticket Processing

The ticket workflow shall support:

• acceptance;
• progress updates;
• closure.

FR-TK-006 — SLA

The system shall track:

• response time;
• processing/resolution time.

SLA targets and timing rules are TBD.

FR-TK-007 — Technical Email Notification

The system shall send configured email notifications to:

• KTV/administrative technical team;
• technical superior/technical escalation recipients;

according to configured rules.

5.9 IoT Device Control

FR-IOT-001 — Device Management

Authorized users shall be able to:

• create;
• view;
• edit;

IoT devices.

FR-IOT-002 — Pond Assignment

The system shall allow sensors and IoT devices to be assigned to individual ponds.

FR-IOT-003 — Device List

The pond device list shall display:

• name;
• type;
• status;
• operating mode;
• connectivity state.

FR-IOT-004 — Control History

The system shall maintain device-control history including:

• device;
• command;
• requesting user;
• request time;
• execution status;
• execution time.

FR-IOT-005 — Automatic Rules

The system shall support automatic device rules based on:

• DO;
• temperature;
• time window;
• alert thresholds.

Exact condition precedence and conflict resolution are TBD.

FR-IOT-006 — Device Non-Response Alert

The system shall automatically create/send a device alert when a device does not respond to a command within a configured period.

Current implementation status: Partial. Pending device commands are marked as TIMEOUT after the configured timeout. Automatic alert creation/sending for that timeout is not yet complete.

FR-IOT-007 — Manual / Auto Mode

Authorized users shall be able to switch a device between:

• manual;
• auto;

according to permission.

FR-IOT-008 — Remote Control

Authorized users shall be able to turn supported devices ON/OFF from:

• Website;
• Mobile App.

Current implementation status: Partial. Backend command publishing, MQTT ACK handling and local IoT-output control exist. Web device management exists; mobile control exists through pond/device flows where wired, but final role/permission and UX coverage should be verified per supported device type.

5.10 Farming Handbook

FR-HB-001 — Article Library

The system shall provide a farming article library with topic areas including:

• farming processes;
• environment;
• feed;
• shrimp diseases/conditions;
• minerals;
• equipment incidents.

FR-HB-002 — Keyword Search

Users shall be able to search articles by keyword.

FR-HB-003 — Article Filters

Users shall be able to filter articles by:

• topic;
• farming stage;
• related indicator.

FR-HB-004 — Alert-Related Content

The system shall display articles relevant to an active alert when related content exists.

Alert-to-article mapping logic is TBD.

FR-HB-005 — Favorite Articles

Users shall be able to mark and unmark articles as favorites.

FR-HB-006 — Article Administration

Admin shall be able to:

• create;
• edit;
• archive;

articles.

FR-HB-007 — Version Management

Admin shall be able to manage article versions.

FR-HB-008 — Reference Integrity

The system shall not permanently delete an article that has already been referenced by AI Chatbot.

Such an article shall instead be moved to:

Archived

Current implementation status: Partial. Article archive/restore and versioning exist. AI Chatbot references are not yet implemented, so reference-integrity enforcement against chatbot usage remains planned.

5.11 AI Chatbot

Current implementation status: Planned. The mobile app currently exposes a placeholder AI Support tab/screen only. The current codebase does not include production chatbot backend APIs for conversation, pond-context assembly, image analysis, confidence, references, escalation, history, feedback or AI authorization enforcement. All requirements in this subsection remain planned unless otherwise noted.

FR-AI-001 — Chatbot Availability

The system shall provide the chatbot on:

• Website;
• Mobile App.

The roadmap specifies availability for all roles, subject to authorization.

Current implementation status: Planned. Mobile has a placeholder entry point; website chatbot UI is not implemented.

FR-AI-002 — Text Q&A

The chatbot shall allow text-based questions and answers.

FR-AI-003 — Pond Selection

Users shall be able to select the related pond before submitting a question.

Only authorized ponds shall be available for pond context.

FR-AI-004 — Image Input

The chatbot shall allow users to upload or capture images of:

• shrimp;
• water;
• feeding tray;
• pond bottom;
• equipment;

for preliminary analysis.

Detailed image-analysis scope is TBD.

FR-AI-005 — Automatic Pond Context

Where the user has permission, chatbot context shall automatically include available:

• pH;
• DO;
• temperature;
• salinity;
• farming day;
• shrimp size;
• latest feeding amount;
• open alerts.

FR-AI-006 — Confidence

The chatbot shall display a confidence level with its response.

Confidence representation and calculation method are TBD.

FR-AI-007 — References

The chatbot shall display reference sources with its response.

Approved source types are TBD.

FR-AI-008 — Escalation

The chatbot shall suggest:

• creating a ticket; or
• sending/escalating to KTV;

when:

• the issue is serious; or
• confidence is low.

Seriousness and low-confidence thresholds are TBD.

FR-AI-009 — Conversation History

The system shall store chatbot conversation history and allow users to review history within their authorization scope.

FR-AI-010 — Response Feedback

Users shall be able to mark a chatbot response as:

• Helpful;
• Not Helpful.

FR-AI-011 — AI Authorization

The chatbot shall not answer using information from a pond the user is not authorized to access.

Authorization must be applied before unauthorized pond context is made available to AI processing.

5.12 System Configuration

FR-SC-001 — Alert Thresholds

Admin shall be able to configure supported alert thresholds by:

• indicator;
• pond;
• shrimp type;
• farming stage.

Configuration precedence is TBD.

Current implementation status: Partial. Global and pond-specific parameter-threshold APIs exist. Shrimp-type and farming-stage precedence remains TBD/planned.

FR-SC-002 — Device Automation

Admin shall be able to configure automatic device ON/OFF rules.

Current implementation status: Implemented for current backend rule model. Rules support device/local-output targets, threshold/time conditions, priority and cooldown. Final conflict-resolution rules remain TBD.

FR-SC-003 — Master Data

Admin shall be able to manage supported categories for:

• feed types;
• minerals;
• devices;
• ticket types;
• alert types.

Current implementation status: Partial. Feed types and crop catalog items exist, while full mineral/device/ticket/alert master-data management is not complete as a unified configuration surface.

FR-SC-004 — Email Configuration

Admin shall be able to configure:

• email templates;
• recipients by event type.

Current implementation status: Partial. Notification configuration and environment-based email recipient settings exist. Full email-template management is planned.

FR-SC-005 — SLA Configuration

Admin shall be able to configure SLA for:

• tickets;
• alerts.

Current implementation status: Partial. Incident-response settings exist for ticket handling. Alert SLA configuration and final SLA timing rules remain TBD.

FR-SC-006 — SaaS Plan

If the product is deployed using SaaS plans, Admin shall be able to configure:

• service plans;
• account limits.

Status: Conditional requirement.

Current implementation status: Planned / conditional. No SaaS plan or account-limit configuration module is present in the current codebase.

FR-SC-007 — AI Configuration

Admin shall be able to configure supported:

• chatbot knowledge;
• chatbot data sources;
• chatbot safety policies.

Current implementation status: Planned. No chatbot knowledge/data-source/safety-policy configuration module is present in the current codebase.

6. Non-Functional Requirements

6.1 Security & Authorization

Current code carries authenticated user role/farm/pond scope through protected APIs and applies it in multiple query paths. However, selected permission checks are temporarily bypassed in code, so authorization must be hardened before the security requirements are considered complete.

6.2 Data Integrity

The system shall preserve historical traceability for operational records where required.

Confirmed examples include:

• feeding history;
• farming logs;
• device control history;
• ticket history;
• user/permission audit logs;
• archived handbook articles and handbook versions.

Planned examples include:

• chatbot conversation history;
• chatbot references to handbook articles.

Detailed retention periods are TBD.

6.3 Reliability

The system shall provide failure visibility for sensor/device operations, including:

• sensor/device offline or error alerts;
• device-command non-response tracking.

Sensor/device offline alerts and device command timeout marking are implemented. Automatic alert creation/sending for command non-response is still partial.

The following targets are not specified in the roadmap:

6.4 Performance

The source does not provide measurable performance requirements.

Numeric targets must be approved before being treated as release criteria.

6.5 Data Freshness

Water monitoring and AI capabilities depend on timely environmental information.

Data-freshness rules are not yet defined for:

• pH;
• DO;
• temperature;
• salinity;
• sensor state;
• feeding data;
• active alerts.

Status: TBD

6.6 Auditability

Critical actions requiring traceability include at minimum:

• user-management changes;
• permission changes;
• device-control commands;
• ticket processing;
• historical operational records.

Current implementation includes audit/activity coverage for several operational events, including user/permission changes and AI prediction logs. Further audit requirements are TBD.

7. Success Metrics

The roadmap does not define approved numeric product KPIs.

The following metrics are recommended for measurement; target values remain TBD.

7.1 Operational Metrics

7.2 AI & Knowledge Metrics

7.3 Critical Quality Indicators

The following outcomes should be treated as critical quality expectations:

8. Yêu cầu AI riêng / AI-Specific Requirements

Các tính năng AI cần được triển khai theo giai đoạn và phải có cơ chế kiểm soát an toàn, nguồn tham chiếu, logging và fallback sang kỹ thuật viên khi cần.

Trong MVP sớm, hệ thống có thể bắt đầu bằng rule-based recommendation trước khi nâng cấp lên AI-based recommendation. Rule-based outputs must be clearly labeled as rule-based recommendations and must not be presented as autonomous AI decisions.

Current implementation status: Planned / Partial. The current codebase contains placeholder or stubbed AI-related surfaces only: mobile AI support placeholder, unavailable AI feeding suggestion endpoint contract, and planned chatbot/reference behavior. No production AI inference, image analysis, prediction engine, growth analysis, energy optimization or complete AI safety workflow is implemented yet.

8.1 AI Capability Roadmap

8.2 AI Safety And Control Requirements

8.3 AI Input And Output Boundaries

AI features may use:

• authorized farm, pond and crop context;
• recent and historical environmental readings;
• feeding history and feed response;
• alert and ticket history;
• device status and control history;
• Farming Handbook content and approved operational procedures;
• uploaded images when image analysis is explicitly supported.

AI features must not use:

• data from farms or ponds outside the user's access scope;
• unapproved knowledge sources for technical recommendations;
• hidden prompts or model outputs as the only audit evidence;
• raw secrets, credentials, tokens or private configuration.

8.4 AI Acceptance Criteria

Before any AI feature is marked implemented, the release must include:

• defined input data contract;
• authorization check before context construction;
• output format and disclaimer behavior;
• source-reference behavior where applicable;
• logging/audit behavior;
• fallback/escalation behavior;
• test cases for low-confidence, missing-data and unauthorized-context scenarios.

8.5 AI Prediction Requirements / Yêu cầu dự đoán AI

AI prediction features must be treated as decision-support outputs, not guaranteed outcomes. Every prediction must include prediction horizon, confidence/uncertainty, source data window, last data timestamp and recommended next action.

Current implementation status: Planned. The current codebase does not include production AI prediction models, prediction APIs, prediction dashboards, model evaluation workflow or historical backtesting.

Prediction Control Requirements

9. Risks and Dependencies

9.1 Product / Business Risks

9.2 Technical Risks

9.3 Dependencies

Appendix A — Product Roadmap

Appendix B — Open Questions

Appendix C — Glossary

Appendix D — Requirement Traceability

Appendix E — Document History

End of Product Requirements Document